Subscriber line validation of a telephone network

ABSTRACT

A method of validating connection data for a node of a telephone network involves processing a report file for terminal pairs at a network node. The records in the report file are divided into three categories in dependence on the nature of the information in each record. A network status database is then updated with the report data category by category. Circuit IDs in the network status database that are deleted by updating in respect of records belonging to other then the last processed category are recorded against a record in the network status database corresponding to a record in the last processed category. Circuit IDs in the network status database that are deleted by updating in respect of last-processed category records are logged to provide a list of circuit IDs for which further investigation is required.

This application is the US national phase of international applicationPCT/GB03/02056 filed 13 May 2003 which designated the U.S. and claimsbenefit of EP 02253416.8, dated 15 May 2002, the entire content of whichis hereby incorporated by reference.

The present invention relates to validating telephone network connectiondata.

Conventional telephone networks consist of millions of copper wire pairslinking exchanges, distribution points and subscriber equipment. At anygiven time, a portion of these pairs will not be allocated to asubscriber and, of the unallocated pairs, a portion will beunserviceable. Furthermore, the set of unallocated pairs changes rapidlywith time as the demand for telephone lines by subscribers changes.

It is in the interest of a telephone network operator to have an up todate record of the state of the copper pairs in its network so that, forinstance, unallocated pairs can be allocated to new connections.However, it is estimated that 20% of a typical established telephonenetwork operator's records for copper pairs are incorrect.

Test equipment exists for checking copper pairs. This equipment includesexchange-based equipment and handheld devices, such as are availablefrom EML Ltd, at Unit 8c, Weldale Street, Reading, Berkshire, RG1 7BXand YP Unitesters at Hod Hasharon P.O. box: 1305, Israel. Generally,equipment of this type produces data files containing the results of thetests carried out. However, these data files are defined by theequipment manufacturers and no means has been provided for updatinglegacy network databases.

According to the present invention, there is provided a method ofvalidating connection data for a node of a telephone network, the methodcomprising:

-   -   generating a report file for terminal pairs at a network node,        the report comprising, for each terminal pair, a record        including data identifying the terminal pair, data identifying        an associated circuit ID (e.g. a telephone number), if any, data        identifying the type of the line, if any, using the terminal        pair and data reporting electrical testing of the line, if any,        using the terminal pair;    -   allocating each record to one of three categories, the first        category comprising terminal pairs for which there is an        associated circuit ID, the second category comprising terminal        pairs for which there is a line type but no circuit ID and the        third category comprising unallocated lines;    -   for each record in the first category, updating a corresponding        record in a network status database in dependence on the record;    -   for each record in the second category, updating a corresponding        record in a network status database in dependence on the record;        and    -   for each record in the third category, updating a corresponding        record in a network status database in dependence on the record,    -   wherein circuit IDs in the network status database that are        deleted by updating in respect of first and second category        records are recorded against a record in the network status        database corresponding to a third category record and circuit        IDs in the network status database that are deleted by updating        in respect of third category records are logged to provide a        list of circuit IDs for which further investigation is required.

Preferably, a record in the network status database is only updated ifit is older than the corresponding record in the report file.

Preferably, updating a circuit ID field in dependence on a first orsecond category record comprises searching for and deleting, if found,the replacing ID in the network status database records corresponding tothe third category records.

Preferably, a method according to the present invention includesperforming a validation process on the records from the report file,determining the proportion of well-formed records and proceeding withthe updating of the network status with the well-formed records only ifthe well-formed records form a predetermined proportion, preferablygreater then 90%, of the records in the report file.

According to the present invention, there is provided a method ofvalidating connection data of a telephone network, the method comprisingthe steps of:

-   -   (a) selecting a telephone network exchange node on the basis of        a spare capacity criterion or a record error criterion;    -   (b) performing a method of validating connection data for a node        according to the present invention in respect of the selected        node; and    -   (c) selecting a further node in dependence on the updating of        the network status database in step (b).

The further node may be a neighbouring telephone exchange node and beselected in the event that a circuit identity associated with theinitially selected node in the network status database has not beenlocated in step (b).

The further node may be a node connected to said initially selected nodeand is selected in the event that a network status database record isaltered in step (b).

An embodiment of the present invention will now be described, by way ofexample, with reference to the accompanying drawings, in which:

FIG. 1 illustrates part of a telephone network;

FIG. 2 is a simplified illustration of the wiring of a secondaryconnection point of FIG. 1;

FIG. 3 illustrates an apparatus for use in performing the presentinvention;

FIG. 4 is a flowchart illustrating the processing of terminal pairreport data according to the present invention;

FIG. 5 is a flowchart of a step of the process shown in FIG. 4; and

FIG. 6 is a flowchart of a method of performing a network-wide audit.

Referring to FIG. 1, a telephone exchange (also known as a “switch”) 1is provided with connections 2, 3 to other exchanges (not shown). Theexchange 1 includes at least one MDF (Main Distribution Frame) 4 havingtypically many thousands of local loop connections. A plurality ofcables, first second and third 5 a, 5 b, 5 c shown, connect the MDF 4 torespective PCPs (Primary Connection Points), first, second and third 6a, 6 b, 6 c shown. Each cable consists of a number of copper pairs, e.g.800.

The third PCP 6 c is connected to a plurality of SCPs (SecondaryConnection Points), first, second and third 7 a, 7 b, 7 c shown. Theother PCPs 6 a, 6 b are similarly connected to SCPs (not shown).

The third SCP 7 c is connected to a plurality of DPs (DistributionPoints), first, second and third 8 a, 8 b, 8 c shown. The other SCPs 7a, 7 b are similarly connected to DPs (not shown).

Finally, the third DP 8 c is connected to a plurality of subscriberequipments 9. The other DPs 8 a, 8 b are similarly connected tosubscriber equipments 9. Additionally, subscriber equipments can beconnected directly to PCPs 6 a, 6 b, 6 c and SCPs 7 a, 7 b, 7 c.

Although the distribution arrangement shown in FIG. 1 has a generallytree-like form, it is not a perfect tree. For example, the third SCP 7 ais connected to the second PCP 6 b as well as the third PCP 6 c and thesecond DP 8 b is connected to the second SCP 7 b as well as the thirdSCP 7 c.

The copper pairs can be tested by means of a fixed test apparatus 10connected to their terminals in the MDF 4 and a portable test apparatus11 which is used to test copper wires at the PCPs 6 a, 6 b, 6 c, SCPs 7a, 7 b, 7 c and DPs 8 a, 8 b, 8 c.

Referring to FIG. 2 which illustrates a simplified SCP 7, the SCP 7 hasan exchange-side terminal strip 12 and a distribution-side terminalstrip 13. The copper pairs of first, second and third cables 14 a, 14 b,14 c are connected to terminals of the exchange-side terminal strip 12.The cables come from PCPs. For instance, in the case of the third SCP 7c, the first cable comes from the second PCP 6 b and the second andthird cables 14 b, 14 c come from the third PCP 6 c. The copper pairsleading to subscriber equipments 9 and DPs 8 a, . . . , 8 c areconnected to the distribution-side terminal strip. Connections are madebetween the exchange-side terminal strip 12 and the distribution-sideterminal strip 13 as required and it can be seen in the present examplesome of the input and output copper pairs are unconnected.

The PCPs 6 a, 6 b, 6 c and DPs 8 a, 8 b, 8 c are similar to the SCPs 7a, 7 b, 7 c but on larger and smaller scales respectively.

The fixed and portable test apparatuses 10, 11 produce reports as textfiles. The reports comprise, for each terminal pair tested, an exchangeID, an node ID, a cable ID, a terminal pair ID, a circuit ID (e.g.telephone number) associated with the terminal pair, a line type code(e.g. analogue PSTN or digital ISDN), a test date, a test code and atest description. The test code and the test description indicate anyfaults detected. It will be appreciated that additional fields may beprovided and that some fields, e.g. test code or test description, maybe omitted.

One of the problems with this form of report is that it cannot be loadedsimply into an existing, or “legacy”, network state database. Manuallyentry is extremely time consuming and bearing in mind the millions ofterminals pairs in a telephone network, a practical impossibility withinthe context of a systematic network-wide audit. Screen scrapingtechnology can be employed to input data into legacy database systems.However, simply applying screen scraping to input the reports is notpossible. The reports for an exchange take typically one week togenerate. However, even during this time, the network is in flux as newconnections are made and old connections are removed and these changeswill be logged into the network state database as they happen.Therefore, it is inevitable that the report data will be incorrect.

The solution to this problem is to process the report data before it isentered into the network state database.

Referring to FIG. 3, a system for use in an embodiment of the presentinvention comprises a personal computer 15 and a remote network statusdatabase 16. The computer 14 has access to the network status database16 and can receive report files 17, by email for example, and processthem for updating the network status database 16.

Referring to FIG. 4, which illustrates the operation of the computer 15for updating the network status database 16, in order to update thenetwork status database 16, a report file 17 is first parsed (step s1).If the parsing fails (step s2), an error is reported (step s3). However,if the parsing succeeds (step s2), the parsed data is validated (steps4).

In the validation step (step s4), the report data is checked for errorssuch as duplicate terminal pair IDs, garbled or mismatching test codesand descriptions. However, a report is not rejected merely because oneerror is found. A report is only rejected (step s5) and an errorreported (step s6), if more than, for example, 46% of the lines in thereport contain errors. Nevertheless, invalid lines will be removed fromthe report dataset, which is saved to a local SQL database, and theidentities of the corresponding terminal pairs logged. The validateddata is then processed and the network state database updated (step s7).

Each terminal pair is placed in one of three categories, categories A, Band C. Category A comprises terminal pairs for which a dial tone wasdetected and for which a call trace was successfully completed, i.e.allocated, fault-free PSTN connections. Category B comprises terminalpairs where the circuit type is known but is of type for which there isno circuit identity, e.g. ISDN connections. Category C contains“unallocated” pairs which may be electrically sound and therefore spareand available for use or electrically unsound.

Referring to FIG. 5, in the processing of the data for each terminalpair in the validated report data, the data for category A terminalpairs is first retrieved from the local SQL database (step s21). Foreach record in the retrieved dataset (steps s22 and s29), it isdetermined whether the record is older than the corresponding entry inthe network status database 16 (step s23). If the record is older, theprocess proceeds to step s30. However, if the record is not older, it isdetermined whether the circuit identity matches the value recorded forthe same terminal pair in the network status database 16 (step s24). Ifthere is a circuit identity match, the process proceeds to step s30.

If there is not a match at step s24, the network status database 16record is corrected. If the new number already exists in the networkstatus database 16 for a terminal pair at the same node 4, 6 a, 6 b, 6c, 7 a, 7 b, 7 c, 8 a, 8 b, 8 c (step s26), the corresponding record isupdated to remove the number (step s27). The number, if any (step s28),originally recorded in the network status database 16 record istransferred notionally to a spare terminal pair at the same side(exchange or distribution) of the same node 4, 6 a, 6 b, 6 c, 7 a, 7 b,7 c, 8 a, 8 b, 8 c (step s29).

When all of the category A terminal pairs have been processed (steps30), the data for the category B terminal pairs is retrieved from thelocal SQL database (step s31).

For each record in the retrieved dataset (steps s32 and s38), it isdetermined whether the record is older than the corresponding entry inthe network status database 16 (step s33). If the record is older, theprocess proceeds to step s38. If the record is not older, it isdetermined whether there is a line type match between the current recordin the retrieved dataset and the corresponding record in the networkstatus database 16 (step s34). If there is a match, the process proceedsto step s38. However, it there is not a match (step s34), the networkstatus database 16 record is corrected (step s35). If this correctioninvolved deleting a circuit identity (step s36), the deleted number istransferred notionally to a spare terminal pair in the same cable (steps37).

When all of the category B terminal pairs have been processed (steps38), the category C terminal pairs are retrieved from the local SQLdatabase (step s39).

For each record in the retrieved dataset (steps s40 and s46), it isdetermined whether the record is older than the corresponding entry inthe network status database 16 (step s41). If the record is older, theprocess proceeds to step s46. If the record is not older, it isdetermined whether the status of the terminal pair, as determined by thetest code and test description, matches that in the corresponding recordof the network status database 16 (step s42). If there is a match, theprocess proceeds to step s46. However, if there is not a match, thenetwork status database 16 is updated with the data from the report(step s43). If the network status database 16 record includes a Circuitidentity, the number is logged (step s45) so that further investigationscan be carried out to locate the actual associated terminal pair.

The above described process can be performed using report data from MDFs4 and the exchange and distribution sides of PCPs 6 a, 6 b, 6 c, SPCs 7a, 7 b, 7 c and DPs 8 a, 8 b, 8 c.

Statistics providing a summary of the process are available. Electricaltest data will not be available for occupied lines. However, theelectrical test results for category C terminal pairs can be used toidentify faulty lines that require repair.

Whilst it would be possible to check every copper pair, this would be amassive undertaking. A further aspect of the present invention relatesto a method for validating connection data for a telephone network toproduce data having a high confidence level without the investment inresources required for a complete test of all copper pairs.

Referring to FIG. 6, initially PCPs which are recorded in the networkstatus database 16 as having few spare copper pairs or for which thenetwork status database 16 data is known to be poor. The quality of thenetwork status database 16 data can be assessed from the frequency oferrors, such as lines allocated to new connections being occupied,detected by engineers (step s51).

The cables linking these PCPs to exchanges, and consequently theassociated MDFs, are then determined (step s52). This provides a list ofMDFs to examine.

Automatic test equipment is installed at the MDFs in the list andreports, as described above, are generated (step s54). These reports arethen processed as described above (step s55).

If any circuit identities are removed from the network status database16 (step s56), an investigation is made of neighbouring MDFs at the sameexchange in order to locate terminal pairs associated with these numbers(step s57). This investigation may be encompassed in an alreadyscheduled test.

For each cable for which a network status database 16 record update hasoccurred (step s58), the terminal pairs of the terminating PCP aretested and the resultant reports processed as described above forupdating the network status database 16 (step s59). Both the exchangeand distribution sides are tested. If any updates are made on thedistribution side, the affected SCPs are then similarly tested andlikewise DPs are selected for testing on the basis of the SCP tests.

It will be appreciated that many modifications may be made to theexemplary embodiment described. For example, a plurality of networkstatus databases may be used to hold the status data for different partsof a network.

1. A method of validating connection data for a node of telephonenetwork, the method comprising: generating a report file for terminalpairs at a network node, the report comprising, for each terminal pair,a record including data identifying the terminal pair, data identifyingan associated circuit ID, if any, data identifying the type of the line,if any, using the terminal pair and data reporting electrical testing ofthe line, if any, using the terminal pair; allocating each record to oneof three categories, the first category comprising terminal pairs forwhich there is an associated circuit ID, the second category comprisingterminal pairs for which there is a line type but no circuit ID and thethird category comprising unallocated lines; for each record in thefirst category, updating a corresponding record in a network statusdatabase in dependence on the record; for each record in the secondcategory, updating a corresponding record in a network status databasein dependence on the record; and for each record in the third category,updating a corresponding record in a network status database independence on the record, wherein circuit IDs in the network statusdatabase that are deleted by updating in respect of first and secondcategory records are recorded against a record in the network statusdatabase corresponding to a third category record and circuit IDs in thenetwork status database that are deleted by updating in respect of thirdcategory records are logged to provide a list of circuit IDs for whichfurther investigation is required.
 2. A method according to claim 1,wherein a record in the network status database is only updated if it isolder than the corresponding record in the report file.
 3. A methodaccording to claim 1, wherein updating a circuit ID field in dependenceon a first or second category record comprises searching for anddeleting, if found, the replacing ID in the network status databaserecords corresponding to the third category records.
 4. A methodaccording to claim 1, including performing a validation process on therecords from the report file, determining the proportion of well-formedrecords and proceeding with the updating of the network status with thewell-formed records only if the well-formed records form a predeterminedproportion of the records in the report file.
 5. A method according toclaim 4, wherein said proportion is greater than 54%.
 6. A method ofvalidating connection data for a telephone network, the methodcomprising the steps of: (a) selecting a telephone network exchange nodeon the basis of a spare capacity criterion or a record error criterion;(b) performing a method according to claim 1 in respect of the selectednode; and (c) selecting a further node in dependence on the updating ofthe network status database in step (b).
 7. A method according to claim6, wherein said further node is a neighbouring telephone exchange nodeand is selected in the event that a circuit identity associated with theinitially selected node in the network status database has not beenlocated in step (b).
 8. A method according to claim 6, wherein saidfurther node is a node connected to said initially selected node and isselected in the event that a network status database record is alteredin step (b).
 9. Apparatus arranged to implement the method of claim 1.10. A computer program comprising a set of instructions to cause acomputer to perform the method according to claim
 1. 11. A suite of atleast one computer programs for use with one or more computers to carryout the method as set out in claim
 1. 12. A method of validatingconnection data for a node of telephone network, the method comprising:generating a report file for terminal pairs at a network node, thereport comprising, for each terminal pair, a record including dataidentifying the terminal pair, and capable of associating with therecord identifying the terminal pair at least one of the following data:data identifying an associated circuit ID, and/or data identifying atype of line using the terminal pair, and/or data reporting electricaltesting of a line using the terminal pair; and for each terminal pair,determining if a circuit ID is associated with the terminal pair;determining if a line type is associated with the terminal pair;allocating each record to one of three categories, the first categorycomprising terminal pairs for which there is an associated circuit ID,the second category comprising terminal pairs for which there is a linetype but no circuit ID and the third category comprising unallocatedlines; for each record in the first category, updating a correspondingrecord in a network status database in dependence on the record; foreach record in the second category, updating a corresponding record in anetwork status database in dependence on the record; and for each recordin the third category, updating a corresponding record in a networkstatus database in dependence on the record, wherein circuit IDs in thenetwork status database that are deleted by updating in respect of firstand second category records are recorded against a record in the networkstatus database corresponding to a third category record and circuit IDsin the network status database that are deleted by updating in respectof third category records are logged to provide a list of circuit IDsfor which further investigation is required.